-
Notifications
You must be signed in to change notification settings - Fork 533
Improve field loading method #505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve field loading method #505
Conversation
is there a way to implement a quick and easy "import all" option? This way we don't have to explicitly list the fields we would have access too. Having to identify each field might be a bit problematic in apps that use dynamic forms ... where we don't know which fields a form will use ahead of time, and therefore have to have all fields loaded and ready to go?
Where |
Remember that we want to remove all fields from VFG. Soon that will not be possible anyway. You will have to add the fields in your dependencies. |
I thought we were keeping the standard/core fields ... such as input, select, checkbox, etc ... as these are the backbone of all other fields and common across just about any form? Not sure I agree with removing "all" fields from VFG Core. |
They can register all the fields if they want. In the end, this only use
Don't worry, this is open for debate, but when we talked about this earlier, I understood you wanted to remove them all. After that, I will do a PR that remove Pug and use more strict EsLint rules. EDIT: BTW, we could also move every field into their own repo and make the "core" field a dependency of VFG. Moving them was also to deal with issues in a more compartmentalized way. |
Moving all the core fields into a single package, and flagging it as a dep of the main package is an ideal solution. That would allow us to keep the main package smaller, and focused on the task of "generating the form" and the core-fields package could be focused on presenting the common "everyday" fields. AbstractField and other common-reusable bits should still be part of the main form-generator package though, so third-party fields can extend from main... say for example, in forms where all elements are "custom" (for specific CSS frameworks, etc). This would allow us to have a "core-bootstrap" and "core-blueprint" package for example, where the common fields are tailored toward either Bootstrap or Blueprint CSS frameworks, etc. |
1d3846c
to
cc52011
Compare
I really want to do a repo by field, and avoid big pack like this. In this I see also a need to group The "dev" folder need to be made into a submodule, so we can have a repo just to launch example (for #32 ) |
Feature
#244
There is a new way to deal with fields.
VFG used to register core and/or optionnal fields in Vue (depending on the version you decided to use).
That mean that internally, VFG was using
Vue.component()
to register all fields.So if you wanted to use only one field or two, your final app had at best, all "core" fields bundled inside.
Now, no fields are added to Vue by default.
You need to pass them as an option.
It still work with custom fields. Meaning now, you can use VFG with your custom fields only.
(If you use a recent version of Webpack or a tool that does tree-shaking, you should have a better bundle size.
Your custom field will need to have the "name" property set to "field-***" (e.g. "field-awesome")
If you want everything like before (full bundle), you need to do that
Be aware that this is the first step toward removing fields from the library and into their own repository.
Soon, VFG will bundle no field at all, and you will need to add them as dependency.
Also, VFG is completely written in ES6 now (
import/export
), no more CommonJS syntax (require/module.exports
). The mix of both caused a bug in Webpack.